In mobile communication networks, e.g., according to the technical specifications (TSs) of the Third Generation Partnership Project (3GPP), there is a general trend to support higher bandwidths for communication of data with a user equipment (UE).
For example, in 3GPP Long Term Evolution (LTE) Release 8, in the following also referred to as LTE Rel-8, bandwidths up to 20 MHz are supported. However, in order to meet upcoming IMT-Advanced requirements (IMT: International Mobile Telecommunications), work on LTE-Advanced was initiated. One of the parts of LTE-Advanced is to support bandwidths larger than 20 MHz. Accordingly, in 3GPP LTE Release 10, in the following also referred to as LTE Rel-10, a concept called “carrier aggregation” is being introduced. According to this concept, multiple component carriers, each of which may be up to 20 MHz wide, may be aggregated together. Carrier aggregation implies that an LTE Rel-10 terminal can receive and send on multiple component carriers. The component carriers may have the same structure as a carrier according to LTE Rel-8.
The aggregated component carriers may be adjacent to each other. However, in more general terms the carrier aggregation may also allow for non-adjacent component carriers, including carriers in different frequency bands, or both adjacent and non-adjacent component carriers. Thus, the introduction of carrier aggregation as part of LTE Rel-10 allows for spectrum aggregation, i.e., the simultaneous usage of different non-contiguous spectrum fragments for communication in a downlink (DL) direction to a single mobile terminal or in an uplink (UL) direction from a single mobile terminal.
Among other things, the carrier aggregation concept allows for supporting higher bit-rates, farming of a non-contiguous spectrum, i.e., to provide high bit-rates and better capacity also in cases when an operator lacks corresponding contiguous spectrum capacities, and/or fast and efficient load balancing between carriers.
It should be noted that carrier aggregation may be implemented as a UE-specific concept. That is to say, one UE may be configured to use some specific component carriers from an available set of component carriers, while a further UE may be configured to use only a single component carrier of the set carrier and a still further UE may be configured to use all of the component carriers of the set. For example, UEs may be configured to use the component carriers of a specific network operator.
Thus, in the above-mentioned carrier aggregation concept, a UE can be configured with one Component Carrier (CC), a carrier of a specific frequency, or multiple CCs, which may be within the same frequency band or different frequency bands. Carrier aggregation may be used in the DL, i.e., for transmissions to the UE, and in the UL, i.e., for transmissions from the UE. Multiple UL and DL CCs are may be configured independently of each other, meaning that they are not necessarily configured as UL/DL pairs, e.g., as in LTE Rel-8.
In LTE Rel-10 there may be up to 5 DL CCs and 5 UL CCs configured for one specific UE.
Typically, the UE initially selects a DL CC and finds, in system information blocks (SIB) of a cell transmitting on that DL CC, information about the corresponding UL CC. The UE then performs a Random Access (RA) on the latter and receives a RA response on the DL CC. Then, a Radio Resource Control (RRC) connection is established. These CCs are referred to as Primary Component Carrier (PCC), in particular as the UL PCC and the DL PCC. The cell to which the UE establishes its RRC connection is referred to as Primary Serving Cell (PCell). The UL PCC may be used for transmission of L1 UL control information. The DL PCC cannot be deactivated. Non-Access Stratum (NAS) information is taken from the DL PCC. When the DL FCC experiences Radio Link Failure (RLF), RRC Connection re-establishment will be triggered, regardless of RLF status on the other DL CCs.
Handover of the FCC to another eNB (evolved NodeB, base station in 3GPP LTE) or another carrier of the same eNB is allowed, but it may require renewal of the Access Stratum (AS) security keys.
In addition to the UL/DL PCC pair, the eNB may configure the UE with additional component carriers, which are referred to as Secondary Component Carrier (SCC). The cell of such a SCC to which the UE connects is also referred to as Secondary Cell (Scell). For a specific UE, the DL SCCs are per default deactivated, but may be activated and deactivated as described in the next section.
To ensure reasonable UE battery consumption when CA is configured, a CC activation/deactivation mechanism for DL SCCs may be provided. Typically, this activation/deactivation mechanism does not apply to the PCC. When a DL SCC is not activated for a specific UE, the UE does not need to receive the corresponding Physical Downlink Control Channel (PDCCH) or Physical Downlink Shared Channel (PDSCH), nor is it required to perform Channel Quality Indicator (CQI) measurements for channel quality estimation. Conversely, when a DL SCC is activated for a specific UE, the UE shall receive the corresponding PDSCH and PDCCH (if present), and is expected to be able to perform CQI measurements. In the UL, a UE may transmit on the Physical Uplink Shared Channel (PUSCH) on any configured UL SCC when the UL SCC is active. The UL SCC may be activated/deactivated together with the corresponding DL SOC.
Other details of the activation/deactivation mechanism for SCCs are:                Explicit activation of DL SCCs is done by Medium Access Control (MAC) signaling from the eNB.        Explicit deactivation of DL SCCs is done by MAC signaling from the eNB.        Implicit deactivation of DL SCCs is also possible. For example, the UE may trigger the deactivation if a surveillance timer expires if no data was received for a time period in order to account for missed deactivation signaling.        DL SCCs can be activated and deactivated individually, and a single activation/deactivation command can activate/deactivate a subset of the configured DL SCCs.        SCCs added to the set of CCs configured for a UE are initially “deactivated”.        
Further, in LTE Rel-8 a feature called DRX (Discontinuous Reception) was introduced. This feature allows the UE to stop monitoring DL data and control channels whenever it is not in “Active Time”. The Active Time comprises, e.g., an onDuration, i.e., a short period of activity (e.g., 2 ms) that occurs once per DRX cycle (e.g., 40 ms) and the time when a timer, referred to as the “drx-InactivityTimer”, is running. The latter is restarted for each DL transmission attempt, i.e., successful or unsuccessful data reception at the UE, and ensures that the UE stays active while continuously receiving data.
Furthermore, when the UE is not able to decode a DL transmission attempt it sends a HARQ NACK, i.e., a negative acknowledgement message of a Hybrid Automatic Repeat Request (HARQ) protocol, and it needs to ensure that it is not in DRX status when the retransmission is to be expected. This is achieved by further timers, referred to as the “HARQ RTT Timer” and “drx-RetransmissionTimer”. The HARQ RTT Timer is started when a DL transmission is indicated to a UE. When the HARQ RTT Timer expires, after a HARQ Round Trip Time (RTT), the drx-RetransmissionTimer is started if the previous reception attempt was not successful, i.e., if a HARQ retransmission is to be expected. The drx-RetransmissionTimer shall ensure a sufficient period of activity after an HARQ RTT Timer expires, i.e., after the earliest arrival time of a retransmission, and may be set in present LTE systems to values between 1 ms, e.g. in case of synchronous retransmission, and several ms, e.g., to account for asynchronous retransmission.
It is assumed that the eNB typically deactivates the DL SCC(s) when the DL data queue in the eNB runs empty, i.e., when there is presently no data for transmission. To do so, it may send a deactivation command with a corresponding MAC Control Element (CE) in the last transport block on one or more of the activated CCs. However, some of the transport blocks might need a HARQ retransmission. If the MAC protocol data unit (PDU) with the MAC CE for deactivation arrives on the first attempt and if the UE strictly follows the deactivation command, the UE will not be able to receive the potential retransmission on deactivated CC.
Accordingly, there is a need for techniques which allow for efficiently controlling deactivation of transmission carriers in a communication system using retransmissions, e.g., retransmissions triggered by repeat requests such as in the above-mentioned HARQ protocol according to 3GPP LTE.